The present invention relates to a mechanism for implementing an efficient microkernel architecture for constructing graphical user interfaces capable of scalable embedded, desktop and network distributed applications. The invention disclosed broadly relates to graphical user interfaces (GUI""s) and particularly relates to the software architectures used to implement them.
Much like operating systems (OS""s) of the 1980""s and earlier, which used a monolithic kernel architecture, windowing systems or graphical user interfaces (GUI""s) of the 1980""s and 1990""s have also been implemented with a monolithic kernel. Graphics drivers, input device drivers, and the other functionality of these GUI""s all exist within the common address space of the GUI kernel.
In the 1990""s, many OS vendors started experimenting with microkernel operating systems, recognizing that this architecture provided the best approach to delivering the new functionality demanded by their customers. For the same reasons that a microkernel architecture has been adopted in the OS community, the GUI community needs to also adopt a microkernel approach.
Description of a Microkernel OS:
The basic idea behind a microkernel architecture is to abstract out the core services or xe2x80x9cprimitivesxe2x80x9d from which the higher level functionality of the environment can be constructed. The resulting microkernel can be relatively simple. The xe2x80x9cartxe2x80x9d of microkernel design is in deciding which core services are essential to have within the kernel, and which should be implemented external to the microkernel. Engineering the architecture requires a constant analysis of conflicting trade-offs as pursuing certain design ideals will adversely impact other goals of the system (eg. performance, flexibility, etc).
Historically, OS functionality was implemented within a monolithic kernel to minimize the number of times time-consuming address space transitions were executed in the process of servicing an application request. Rather than having all of the functionality of the OS implemented in a single monolithic kernel that application processes call into, a microkernel OS is implemented as a tiny kernel that does only inter-process communication (IPC) and process scheduling. External processes then use these core services to implement the remainder of the OS functionality. The removal of complexity from the kernel allows a more efficient IPC implementation, which reduces the performance penalty incurred (from communicating with external service-providing processes) to the point that it becomes comparable in performance to the monolithic functional equivalent.
Splitting the monolithic kernel into separate processes also enables the easier implementation of new functionality. For example, by making the microkernel IPC network transparent, the service providing processes can be run on any node on a network, yet still be locally accessible to application processes. This serves to make all resources available to all processes, whether local or network remote. Monolithic kernels have a very difficult time attempting this functionality with efficiency because the xe2x80x9csingle component kernelxe2x80x9d cannot be easily split across processor boundaries.
Problems With the Current State of the Art:
Network distributed computing environments and embedded GUI applications have become common due to increasing integration and decreasing hardware costs. Customer demands for even greater flexibility continue to increase. For example, the growing popularity of mobile hand-held computing devices or Personal Digital Assistants (PDA""s). For reasons of cost sensitivity, battery life and physical size restrictions, the hardware resources of PDA""s are significantly more limited than those of conventional desktop systems. As a result, there is a need for PDA software to make efficient use of these limited resources, which presents a number of challenges to developers. This is one example where many of the GUI development obstacles are satisfied by the inherent design flexibility of a microkernel architecture.
Since a desktop system can run a more complete version of the same software environment that will run on an embedded application platform, the desktop PC also becomes a natural development platform for the embedded application, rather than incurring the inconvenience of a cross-development environment. Being able to use visual and textual tools to directly create, compile and debug the PDA or embedded applications on a workstation or PC minimizes the development effort and reduces the xe2x80x9ctime to marketxe2x80x9d.
Rapidly evolving hardware capabilities also requires that the software environment be able to rapidly accommodate modifications to support that hardware, both as variations of common hardware devices, and as entirely new types of hardware, requiring more substantial changes to the underlying software environment""s capabilities.
Existing GUI""s cannot be scaled small enough to fit within the resource constraints of low-end PDA""s and embedded systems. As a result, a need has been created for a GUI adaptable to both low-end, resource-constrained systems, and large-scale, network distributed systems. Existing monolithic GUI designs cannot simultaneously accommodate these requirements. As a result, vendors are forced to create multiple, completely distinct, GUI products to attempt to address the various markets, while their current monolithic product offerings still fail to address the distributed networking needs. This results in duplication of development and maintenance efforts relating to the GUI, as well as to required drivers, and raises compatibility concerns.
It is therefore desirable to create a microkernel GUI with many of the same attributes as a microkernel OS, using the approach of a tiny microkernel that implements only a few primitives. With such an approach, a team of external cooperating processes invoking those microkernel services could be used to construct a windowing system. An important aspect of such a design is to decide what those primitives should be, such that a high-performance, high-functionality, high-flexibility GUI can be built from the GUI microkernel. Inappropriate design decisions in the microkernel could result in a poor-performing system, due to additional overhead incurred from the IPC between the cooperating processes. A microkernel design would have to recover this IPC performance overhead through architectural and design performance advantages accrued from other aspects of the GUI, such as greater concurrency.
A microkernel GUI would have a number of advantages over monolithic kernel GUI""s, advantages which equate directly to both better functionality and unique capabilities.
a) Scalability: Simply by including or excluding service-providing processes associated with the microkernel GUI, the functionality (and resource requirements) of the GUI could be scaled to address different application needs ranging from small embedded systems to high-end, high-functionality systems. The vendor would only have to create and maintain a single GUI product, rather than a family of products for different environments.
b) Extensibility: As new functionality requirements arise (eg. handwriting recognition, voice recognition, etc.) a microkernel GUI can easily be extended by adding specific service-providing processes. Moreover, these functionality enhancements can be readily accomplished by application developers, rather than requiring (or waiting for) the GUI vendor to implement them. To accommodate additions with a monolithic kernel GUI, the entire GUI would have to be replaced with a new, enhanced version by the GUI vendor. If a developer needs a unique extension, the microkernel approach lets the developer develop those extensions himself, rather than be bound by the original implementation limits.
c) Address protection: With the components of the GUI running in separate, MMU-protected (memory management unit) address spaces, coding errors in one section of the GUI would be contained, and could not cause problems in other sections. Latent bugs in the code would also be likely to xe2x80x9ctripxe2x80x9d the MMU protection, leading to the early detection of programming errors, rather than have them discovered by end-users of the application. In general, this allows the extensions developed (either by the software vendor or an application developer) to be easily and reliably integrated into the GUI, and results in a more robust GUI.
d) Concurrency: With the GUI running as several concurrent processes, it could demonstrate greater concurrency in it""s processing than a single-threaded monolithic kernel GUI. Multiple components of the GUI, since they""re implemented as separate processes, can execute concurrently, especially if they""re running on different nodes on the network. Although a monolithic GUI could use multiple threads of execution within the monolithic GUI kernel, the complexities of semaphores and mutexes would make it difficult to implement the GUI robustly with the same degree of concurrency. The threaded monolithic kernel also cannot make use of multiple processors except in an SMP (symmetric multiprocessor). The microkernel approach can make use of processors on other network nodes.
e) Network Distribution: If the underlying IPC used by the microkernel GUI was network transparent, all of the components of the GUI could be run on different processors in a distributed system. This would enable a class of distributed GUI capabilities not available using a monolithic GUI. For example, applications could be dragged from one computer""s screen onto the screen of a hand-held device connected using a wireless LAN link. This is not possible with a monolithic GUI because the monolithic GUI kernel cannot be broken into separate pieces, each running on a different node on the network.
It is an object of this invention to provide a system for managing the interaction of programs, comprising means for storing a set of predetermined characteristics respecting each program to be managed, each set of characteristics including an input signal type characteristic indicative of the identity of the type of inputs signals to which the program associated with the set of characteristics is responsive and a signal modification characteristic indicative of whether a type of input signal is to be modified by the associated program; means responsive to input signals having predetermined properties emitted from one of the programs for interrogating each set of predetermined characteristics in a predetermined sequence, determining whether the associated program is responsive to a current input signal, determining whether the properties of the current input signal are to be modified and, if so, modifying the properties of the input signal; and means for emitting an output signal to the programs determined to be responsive to the input signal.
Further features of this invention will be apparent from the following description and appended claims.